Skip Headers

Oracle® Data Guard Concepts and Administration 10g Release 2 (10.2) Part Number B14239-04 |
Home | Book List | Contents | Index | Master Index | Feedback

Previous | Next
| View PDF

# 14 LOG_ARCHIVE_DEST_n Parameter Attributes

This chapter provides reference information for the attributes of the `LOG_ARCHIVE_DEST_``n` initialization parameter. The following list shows the attributes:

AFFIRM and NOAFFIRM
ALTERNATE
ARCH and LGWR
DB_UNIQUE_NAME
DELAY
DEPENDENCY
LOCATION and SERVICE
MANDATORY and OPTIONAL
MAX_CONNECTIONS
MAX_FAILURE
NET_TIMEOUT
NOREGISTER
REOPEN
SYNC and ASYNC
TEMPLATE
VALID_FOR
VERIFY

Each `LOG_ARCHIVE_DEST_``n` destination must contain either a `LOCATION` or `SERVICE` attribute to specify a local disk directory or a remotely accessed database, respectively. All other attributes are optional.

Note: Several attributes of the `LOG_ARCHIVE_DEST_``n` initialization parameter have been deprecated. These attributes are supported for backward compatibility only and are documented in the Oracle Database Reference.

See Also: Chapter 5 for more information about defining `LOG_ARCHIVE_DEST_``n` destinations and setting up redo transport services.

## AFFIRM and NOAFFIRM

Controls whether redo transport services use synchronous or asynchronous I/O to write redo data to disk:

- `AFFIRM`—specifies that all disk I/O to archived redo log files and standby redo log files is performed synchronously and completes successfully before the log writer process continues.

- `NOAFFIRM`—specifies that all disk I/O to archived redo log files and standby redo log files is performed asynchronously; the log writer process on the primary database does not wait until the disk I/O completes before continuing.

Category | AFFIRM | NOAFFIRM
--- | --- | ---
Data type | Keyword | Keyword
Valid values | Not applicable | Not applicable
Default Value | Not applicable | Not applicable
Requires attributes ... | Not applicable | Not applicable
Conflicts with attributes ... | `NOAFFIRM` | `AFFIRM`
Corresponds to ... | `AFFIRM` and `ASYNC_BLOCKS` columns of the `V$ARCHIVE_DEST` view | `AFFIRM` and `ASYNC_BLOCKS` columns of the `V$ARCHIVE_DEST` view

Usage Notes

- These attributes are optional. If neither the `AFFIRM` nor the `NOAFFIRM` attribute is specified, the default is `NOAFFIRM`.

- The `AFFIRM` attribute specifies that all disk I/O to archived redo log files and standby redo log files is performed synchronously and must complete before the log writer process continues. The `AFFIRM` attribute:

  - Is one of the required attributes to ensure no data loss will occur if the primary database fails.

  - Can be specified with either the `LOCATION` or `SERVICE` attributes for archival operations to local or remote destinations.

  - Can potentially affect primary database performance, as follows:

    - When you specify the `LGWR` and `AFFIRM` attributes, the log writer process synchronously writes the redo data to disk, control is not returned to the user until the disk I/O completes, and online redo log files on the primary database might not be reusable until archiving is complete.

    - When you specify the `ARCH` and `AFFIRM` attributes, ARCn processes synchronously write the redo data to disk, the archival operation might take longer, and online redo log files on the primary database might not be reusable until archiving is complete.

    - When you specify the `ASYNC` and `AFFIRM` attributes, performance is not affected.

  Note: When the primary database is in the maximum protection or maximum availability mode, destinations defined with the `LGWR` and `SYNC` attributes are automatically placed in `AFFIRM` mode.

- The `NOAFFIRM` attribute specifies that all disk I/O to archived redo log files and standby redo log files is performed asynchronously; the log writer process on the primary database does not wait until the disk I/O completes before continuing.

- The `AFFIRM` and `NOAFFIRM` attributes apply only to archived redo log files and standby redo log files on remote standby destinations and have no effect on disk I/O for the primary database's online redo log files.

- These attributes can be specified with either the `LOCATION` attribute for local destinations or with the `SERVICE` attribute for remote destinations.

See also: SYNC and ASYNC attributes

Examples

The following example shows the `AFFIRM` attribute for a remote destination.

    LOG_ARCHIVE_DEST_3='SERVICE=stby1 LGWR SYNC AFFIRM'
    LOG_ARCHIVE_DEST_STATE_3=ENABLE

## ALTERNAT E

Specifies an alternate archiving destination to be used when the original destination fails.

Category | ALTERNATE=LOG_ARCHIVE_DEST_`n`
--- | ---
Data Type | String
Valid Value | A `LOG_ARCHIVE_DEST_``n` destination
Default Value | None. If an alternate destination is not specified, then redo transport services do not automatically change to another destination.
Requires attributes ... | Not applicable
Conflicts with attributes ... | None Foot 1
Corresponds to ... | `ALTERNATE` and `STATUS` columns of the `V$ARCHIVE_DEST` view

Footnote 1 If the `REOPEN` attribute is specified with a nonzero value, the `ALTERNATE` attribute is ignored. If the `MAX_FAILURE` attribute is also specified with a nonzero value, and the failure count exceeds the specified failure threshold, the `ALTERNATE` destination is enabled. Therefore, the `ALTERNATE` attribute does not conflict with a nonzero `REOPEN` attribute value.

Usage Notes

- The `ALTERNATE` attribute is optional. If an alternate destination is not specified, then redo transport services do not automatically change to another destination if the original destination fails.

- You can specify only one alternate destination for each `LOG_ARCHIVE_DEST_``n` parameter, but several enabled destinations can share the same alternate destination.

- Ideally, an alternate destination should specify either:

  - A different disk location on the same local standby database system (shown in Example 14-1)

  - A different network route to the same standby database system (shown in Example 14-2)

  - A remote standby database system that closely mirrors that of the enabled destination

- If no enabled destinations reference an alternate destination, the alternate destination is implied to be deferred, because there is no automatic method of enabling the alternate destination. However, you can enable (or defer) alternate destinations at runtime using either `ALTER SYSTEM`.

- Any destination can be designated as an alternate destination, given the following restrictions:

  - At least one local mandatory destination is enabled.

  - The number of enabled destinations must meet the defined `LOG_ARCHIVE_MIN_SUCCEED_DEST` parameter value.

  - A destination cannot be its own alternate.

- Increasing the number of enabled destinations decreases the number of available alternate archiving destinations.

- When a destination fails, its alternate destination is enabled on the next archival operation. There is no support for enabling the alternate destination in the middle of the archival operation because that would require rereading already processed blocks, and so forth. This is identical to the `REOPEN` attribute behavior.

- If the `REOPEN` attribute is specified with a nonzero value, the `ALTERNATE` attribute is ignored unless the `MAX_FAILURE` attribute has a nonzero value. If the `MAX_FAILURE` and `REOPEN` attributes have nonzero values and the failure count exceeds the specified failure threshold, the `ALTERNATE` destination is enabled. Therefore, the `ALTERNATE` attribute does not conflict with a nonzero `REOPEN` attribute value.

Examples

In the sample initialization parameter file in Example 14-1, `LOG_ARCHIVE_DEST_1` automatically fails over to `LOG_ARCHIVE_DEST_2` on the next archival operation if an error occurs or the device becomes full.

Example 14-1 Automatically Failing Over to an Alternate Destination

    LOG_ARCHIVE_DEST_1='LOCATION=/disk1 MANDATORY ALTERNATE=LOG_ARCHIVE_DEST_2'
    LOG_ARCHIVE_DEST_STATE_1=ENABLE
    LOG_ARCHIVE_DEST_2='LOCATION=/disk2 MANDATORY'
    LOG_ARCHIVE_DEST_STATE_2=ALTERNATE

Notice in the example that a destination can also be in the `ALTERNATE` state, as specified with the `LOG_ARCHIVE_DEST_STATE_``n` initialization parameter. The `ALTERNATE` state defers redo transport services from transmitting redo data to this destination until such time as another destination failure automatically enables this destination. Section 5.2.2 provides more information about the `LOG_ARCHIVE_DEST_STATE_``n` parameter.

Example 14-2 Defining an Alternate Oracle Net Service Name to the Same Standby Database

This example shows how to define an alternate Oracle Net service name to the same standby database.

    LOG_ARCHIVE_DEST_1='LOCATION=/disk1 MANDATORY'
    LOG_ARCHIVE_DEST_STATE_1=ENABLE
    LOG_ARCHIVE_DEST_2='SERVICE=stby1_path1 OPTIONAL ALTERNATE=LOG_ARCHIVE_DEST_3'
    LOG_ARCHIVE_DEST_STATE_2=ENABLE
    LOG_ARCHIVE_DEST_3='SERVICE=stby1_path2 OPTIONAL'
    LOG_ARCHIVE_DEST_STATE_3=ALTERNATE

## ARCH and LGWR

Specifies whether redo transport services use archiver processes (ARCn) or the log writer process (LGWR) to collect transaction redo data and transmit it to standby destinations. If neither the `ARCH` or `LGWR` attributes are specified, the default is `ARCH`.

Category | ARCH | LGWR
--- | --- | ---
Data Type | Keyword | Keyword
Valid values | Not applicable | Not applicable
Default value | Not applicable | Not applicable
Requires attributes ... | None | None
Conflicts with attributes ... | `LGWR`, `ASYNC`, `NET_TIMEOUT` | `ARCH`
Corresponds to ... | `ARCHIVER`, `PROCESS`, and `SCHEDULE` columns of the `V$ARCHIVE_DEST` view | `ARCHIVER`, `PROCESS`, and `SCHEDULE` columsn of the `V$ARCHIVE_DEST` view

Usage Notes

- These attributes are optional. If neither the `ARCH` or `LGWR` attribute is specified, the default is `ARCH`.

- Redo transport services use ARCn processes when the `ARCH` attribute is specified, and the log writer process when the `LGWR` attribute is specified.

  By default, archiving is performed by ARCn processes; you must explicitly specify the `LGWR` attribute for redo transport services to use the LGWR process. Although you cannot specify both LGWR and ARCn processes for the same destination, you can choose to use the log writer process for some destinations, while archiver processes transmit redo data for other destinations.

- If you change a destination's current archival process (for example, from the ARCn process to the LGWR process), archival processing does not change until the next log switch occurs.

Example

The following example shows the `LGWR` attribute with the `LOG_ARCHIVE_DEST_``n` parameter. See Section 5.3 for more examples.

    LOG_ARCHIVE_DEST_3='SERVICE=denver LGWR'
    LOG_ARCHIVE_DEST_STATE_3=ENABLE

## DB_UNIQUE_NAME

Specifies a unique name for the database at this destination.

Category | DB_UNIQUE_NAME=name
--- | ---
Data Type | String
Valid values | The name must match the value that was defined for this database with the `DB_UNIQUE_NAME` parameter.
Default value | None
Requires attributes ... | None
Conflicts with attributes ... | None
Corresponds to ... | `DB_UNIQUE_NAME` column of the `V$ARCHIVE_DEST` view

Usage Notes

- This attribute is optional if:

  - The `LOG_ARCHIVE_CONFIG=DG_CONFIG` initialization parameter is not specified.

  - This is a local destination (specified with the `LOCATION` attribute).

- This attributes is required if the `LOG_ARCHIVE_CONFIG=DG_CONFIG` initialization parameter is specified and if this is a remote destination (specified with the `SERVICE` attribute).

- Use the `DB_UNIQUE_NAME` attribute to clearly identify the relationship between a primary and standby databases. This attribute is particularly helpful if there are multiple standby databases in the Data Guard configuration.

- The name specified by the `DB_UNIQUE_NAME` must match one of the `DB_UNIQUE_NAME` values in the `DG_CONFIG` list. Redo transport services validate that the `DB_UNIQUE_NAME` attribute of the database at the specified destination matches the `DB_UNIQUE_NAME` attribute or the connection to that destination is refused.

- The name specified by the `DB_UNIQUE_NAME` attribute must match the name specified by the `DB_UNIQUE_NAME` initialization parameter of the database identified by the destination.

Example

In the following example, the `DB_UNIQUE_NAME` parameter specifies `boston` (`DB_UNIQUE_NAME=boston`), which is also specified with the `DB_UNIQUE_NAME` attribute on the `LOG_ARCHIVE_DEST_1` parameter. The `DB_UNIQUE_NAME` attribute on the `LOG_ARCHIVE_DEST_2` parameter specifies the `chicago` destination. Both `boston` and `chicago` are listed in the `LOG_ARCHIVE_CONFIG=DG_CONFIG` parameter.

    DB_UNIQUE_NAME=boston
    LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston,denver)'
    LOG_ARCHIVE_DEST_1='LOCATION=/arch1/
      VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
      DB_UNIQUE_NAME=boston'
    LOG_ARCHIVE_DEST_2='SERVICE=Sales_DR
      VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
      DB_UNIQUE_NAME=chicago'

## DE LAY

Specifies a time lag between when redo data is archived on a standby site and when the archived redo log file is applied to the standby database.

Category | DELAY[=minutes]
--- | ---
Data Type | Numeric
Valid values | >=0 minutes
Default Value | 30 minutes
Requires attributes ... | `SERVICE`
Conflicts with attributes ... | `LOCATION`
Corresponds to ... | `DELAY_MINS` and `DESTINATION` columns of the `V$ARCHIVE_DEST` view

Usage Notes

- The `DELAY` attribute is optional. By default there is no delay.

- The `DELAY` attribute indicates the archived redo log files at the standby destination are not available for recovery until the specified time interval has expired. The time interval is expressed in minutes, and it starts when the redo data is successfully transmitted to, and archived at, the standby site.

- The `DELAY` attribute may be used to protect a standby database from corrupted or erroneous primary data. However, there is a tradeoff because during failover it takes more time to apply all of the redo up to the point of corruption.

- The `DELAY` attribute does not affect the transmittal of redo data to a standby destination.

- If you have real-time apply enabled, any delay that you set will be ignored.

- Changes to the `DELAY` attribute take effect the next time redo data is archived (after a log switch). In-progress archiving is not affected.

- You can override the specified delay interval at the standby site, as follows:

  - For a physical standby database:

        SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;

  - For a logical standby database:

        SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY;

See Also: Oracle Database SQL Reference for more information about these `ALTER DATABASE` statements

Examples

You can use the `DELAY` attribute to set up a configuration where multiple standby databases are maintained in varying degrees of synchronization with the primary database. However, this protection incurs some overhead during failover, because it takes Redo Apply more time to apply all the redo up to the corruption point.

For example, assume primary database A has standby databases B and C. Standby database B is set up as the disaster recovery database and therefore has no time lag. Standby database C is set up with a 2-hour delay, which is enough time to allow user errors to be discovered before they are propagated to the standby database.

The following example shows how to specify the `DELAY` attribute for this configuration:

    LOG_ARCHIVE_DEST_1='LOCATION=/oracle/dbs/'
    LOG_ARCHIVE_DEST_STATE_1=ENABLE
    LOG_ARCHIVE_DEST_2='SERVICE=stbyB LGWR SYNC AFFIRM'
    LOG_ARCHIVE_DEST_STATE_2=ENABLE
    LOG_ARCHIVE_DEST_3='SERVICE=stbyC DELAY=120'
    LOG_ARCHIVE_DEST_STATE_3=ENABLE

Note: Alternatively, you can use Flashback Database to revert the database to a point-in-time or SCN in a different database incarnation as long as there is sufficient flashback log data. Using Flashback Database is described in Oracle Database Backup and Recovery Basics.

## DEPENDENCY

Specify this attribute for a standby destination that will receive redo data through shared access to an archival location at another destination. A destination defined with this attribute has a dependency on another destination, which is specified by the `DEPENDENCY` attribute.

Category | DEPENDENCY=LOG_ARCHIVE_DEST_`n`
--- | ---
Data Type | String value
Valid values | Not applicable
Default Value | None
Requires attributes ... | `SERVICE`
Conflicts with attributes ... | `LOCATION`, `NOREGISTER`
Corresponds to ... | `DEPENDENCY` column of the `V$ARCHIVE_DEST` view

Usage Notes

- The `DEPENDENCY` attribute is optional. If you do not specify the `DEPENDENCY` attribute, redo transport services transmit redo data directly to the destination.

- The `DEPENDENCY` attribute can be specified on a physical standby database or a logical standby database.

  See Also: Section 5.7.5, "Sharing a Log File Destination Among Multiple Standby Databases"

- The availability of redo data at a dependent destination relies on the success or failure of redo transmission to the destination that is specified by the `DEPENDENCY` attribute.

- The `DEPENDENCY` attribute has the following restrictions:

  - Only standby destinations can have a dependency.

  - The destination specified by the `DEPENDENCY` attribute can use either the `LOCATION` or `SERVICE` attribute.

  - The `DEPENDENCY` attribute cannot be modified at the session level.

- When one or more destinations are dependent on the same destination, all attributes specified for the dependent destinations still apply. It appears as if the archival operation was performed for each destination, when only one archival operation actually occurred.

  For example, consider that two standby databases are dependent upon the same destination. You can specify different `DELAY` attributes for each destination, which enables you to maintain a staggered time lag between the primary database and each standby database.

  Similarly, a dependent destination can specify an `ALTERNATE` destination, which itself might or might not be dependent on the same parent destination.

- A zero data-loss failover cannot be performed to a dependent destination.

Examples

One reason to use the `DEPENDENCY` attribute is if two standby databases reside on the same system. The parent and child standby databases can be any mix of physical and logical standby databases. For example:

    # Set up the mandatory local destination:
    #
    LOG_ARCHIVE_DEST_1='LOCATION=/oracle/dbs/ MANDATORY'
    LOG_ARCHIVE_DEST_STATE_1=ENABLE
    #
    # Set up the remote standby database that will receive the redo data:
    #
    LOG_ARCHIVE_DEST_2='SERVICE=dest2 OPTIONAL'
    LOG_ARCHIVE_DEST_STATE_2=ENABLE
    #
    # Set up the remote standby database that resides on the same system as, and is
    # dependent on, the first standby database:
    #
    LOG_ARCHIVE_DEST_3='SERVICE=dest3 DEPENDENCY=LOG_ARCHIVE_DEST_2 OPTIONAL'
    LOG_ARCHIVE_DEST_STATE_3=ENABLE

## LOCATION and SERVICE

Each destination must specify either the `LOCATION` or the `SERVICE` attribute to identify either a local disk directory or a remote database destination where redo transport services can transmit redo data.

Category | LOCATION=local_disk_directory or `USE_DB_RECOVERY_FILE_DEST` | SERVICE=net_service_name
--- | --- | ---
Data type | String value | String value
Valid values | Not applicable | Not applicable
Default Value | None | None
Requires attributes ... | Not applicable | Not applicable
Conflicts with attributes ... | `SERVICE`, `DELAY`, `DEPENDENCY`, `NOREGISTER`, `ASYNC`, `TEMPLATE`, `NET_TIMEOUT` | `LOCATION`
Corresponds to ... | `DESTINATION` and `TARGET` columns of the `V$ARCHIVE_DEST` view | `DESTINATION` and `TARGET` columns of the `V$ARCHIVE_DEST` view

Usage Notes

- Either the `LOCATION` or the `SERVICE` attribute must be specified. There is no default.

- If you are specifying multiple attributes, specify the `LOCATION` or `SERVICE` attribute first in the list of attributes.

- You must specify at least one local disk directory with the `LOCATION` attribute. This ensures the local archived redo log files are accessible should media recovery of the primary database be necessary. You can specify up to nine additional local or remote destinations. Specifying remote destinations with the `SERVICE` attribute ensures Data Guard can maintain a transactionally consistent remote copy of the primary database for disaster recovery.

- For the `LOCATION` attribute, you can specify one of the following:

  - `LOCATION=`local_disk_directory

    This specifies a unique directory path name for a disk directory on the system that hosts the database. This is the local destination for archived redo log files.

  - `LOCATION=USE_DB_RECOVERY_FILE_DEST`

    To configure a flash recovery area, you specify the directory or Oracle Storage Manager disk group that will serve as the flash recovery area using the `DB_RECOVERY_FILE_DEST` initialization parameter. If no local destinations are defined and a flash recovery area has been configured, Data Guard implicitly uses the `LOG_ARCHIVE_DEST_10` destination for the flash recovery area. See Section 5.2.3 for more information about flash recovery areas.

- When you specify a `SERVICE` attribute:

  - You identify remote destinations by specifying the `SERVICE` attribute with a valid Oracle Net service name (`SERVICE=`net_service_name) that identifies the remote Oracle database instance to which the redo data will be sent.

    The Oracle Net service name that you specify with the `SERVICE` attribute is translated into a connection descriptor that contains the information necessary for connecting to the remote database.

    See Also: Oracle Database Net Services Administrator's Guide for details about setting up Oracle Net service names

  - Transmitting redo data to a remote destination requires a network connection and an Oracle database instance associated with the remote destination to receive the incoming redo data.

- To verify the current settings for `LOCATION` and `SERVICE` attributes, query the `V$ARCHIVE_DEST` fixed view:

  - The `TARGET` column identifies if the destination is local or remote to the primary database.

  - The `DESTINATION` column identifies the values that were specified for a destination. For example, the destination parameter value specifies the Oracle Net service name identifying the remote Oracle instance where the archived redo log files are located.

Examples

Example 1 Specifying the LOCATION Attribute

    LOG_ARCHIVE_DEST_2='LOCATION=/disk1/oracle/oradata/payroll/arch/'
    LOG_ARCHIVE_DEST_STATE_2=ENABLE

Example 2 Specifying the SERVICE Attribute

    LOG_ARCHIVE_DEST_3='SERVICE=stby1'
    LOG_ARCHIVE_DEST_STATE_3=ENABLE

## MANDATORY and OPTIONAL

Specifies the policy for reusing online redo log files:

- `MANDATORY`—specifies that filled online log files must be successfully archived to the destination before they can be reused.

- `OPTIONAL`—specifies that successful archival to the destination is not required before the online redo log file can be made available for reuse.

Category | MANDATORY | OPTIONAL
--- | --- | ---
Data type | Keyword | Keyword
Valid values | Not applicable | Not applicable
Default value | Not applicable | Not applicable
Requires attributes ... | Not applicable | Not applicable
Conflicts with attributes ... | Optional | Mandatory
Corresponds to ... | `BINDING` column of the `V$ARCHIVE_DEST` view | `BINDING` column of the `V$ARCHIVE_DEST` view

Usage Notes

- If neither the `MANDATORY` nor the `OPTIONAL` attribute is specified, the default is `OPTIONAL`.

  At least one destination must succeed even if all destinations are designated as optional. If a destination is optional, archiving to that destination may fail, yet the online redo log file is available for reuse and may be overwritten eventually. If the archival operation of a mandatory destination fails, online redo log files cannot be overwritten.

- The `LOG_ARCHIVE_MIN_SUCCEED_DEST=`n parameter (where n is an integer from 1 to 10) specifies the number of destinations that must archive successfully before the log writer process can overwrite the online redo log files.

  All `MANDATORY` destinations and non-standby `OPTIONAL` destinations contribute to satisfying the `LOG_ARCHIVE_MIN_SUCCEED_DEST=`n count. If the value set for the `LOG_ARCHIVE_MIN_SUCCEED_DEST` parameter (that defines the minimum number of destinations that must receive redo data successfully before the log writer process on the primary database can reuse the online redo log file) is met, the online redo log file is available for reuse. For example, you can set the parameter as follows:

      # Database must archive to at least two locations before
      # overwriting the online redo log files.
      LOG_ARCHIVE_MIN_SUCCEED_DEST = 2

- You must have at least one local destination, which you can declare `OPTIONAL` or `MANDATORY`.

  At least one local destination is operationally treated as mandatory, because the minimum value for the `LOG_ARCHIVE_MIN_SUCCEED_DEST` parameter is 1.

- The failure of any mandatory destination, including a mandatory standby destination, makes the `LOG_ARCHIVE_MIN_SUCCEED_DEST` parameter irrelevant.

- The `LOG_ARCHIVE_MIN_SUCCEED_DEST` parameter value cannot be greater than the number of mandatory destinations plus the number of optional local destinations.

- These attributes do not affect the data protection mode for the destination.

- The `BINDING` column of the `V$ARCHIVE_DEST` fixed view specifies how failure affects the archival operation

Examples

The following example shows the `MANDATORY` attribute:

    LOG_ARCHIVE_DEST_1='LOCATION=/arch/dest MANDATORY'
    LOG_ARCHIVE_DEST_STATE_1=ENABLE
    LOG_ARCHIVE_DEST_3='SERVICE=denver MANDATORY'
    LOG_ARCHIVE_DEST_STATE_3=ENABLE

## MAX_CONNECTION S

Specifies the maximum number of network connections that will be used to perform remote archival to the destination. If the `MAX_CONNECTIONS` attribute is set to a value greater than 1, redo transport services use multiple network connections to perform remote archivals. Each of these connections use a separate archiver (ARCn) process.

Category | Description
--- | ---
Data type | Integer
Valid values | 1 to 5
Default value | 1
Requires attributes ... | None
Conflicts with attributes ... | None
Corresponds to ... | `MAX_CONNECTIONS` column of the `V$ARCHIVE_DEST` view of the primary database `LOG_ARCHIVE_MAX_PROCESSES` and `PARALLEL_MAX_SERVERS` initialization parameters

Usage Notes

- The `MAX_CONNECTIONS` attribute is optional. By default redo transport services use a single network connection to perform a remote archival.

  If the `MAX_CONNECTIONS` attribute is set to a value greater than 1, redo transport services use multiple network connections to perform a remote archival to the destination.

- The `LOG_ARCHIVE_MAX_PROCESSES` and `PARALLEL_MAX_SERVERS` initialization parameters are related to the `MAX_CONNECTIONS` attribute and affect the actual number of ARCn processes used by an instance.

  For example, if the total of `MAX_CONNECTIONS` attributes on all destinations exceeds the value of `LOG_ARCHIVE_MAX_PROCESSES`, then Data Guard will use as many ARCn processes as possible but the number of connections may be less than is specified by `MAX_CONNECTIONS`.

Examples

The following example shows the `MAX_CONNECTIONS` attribute:

    LOG_ARCHIVE_DEST_1='LOCATION=/arch/dest'
    LOG_ARCHIVE_DEST_STATE_1=ENABLE
    LOG_ARCHIVE_DEST_3='SERVICE=denver MAX_CONNECTIONS=3'
    LOG_ARCHIVE_DEST_STATE_3=ENABLE

## MAX_FAILURE

Controls the consecutive number of times redo transport services attempt to reestablish communication and transmit redo data to a failed destination before the primary database gives up on the destination.

Category | MAX_FAILURE=count
--- | ---
Data type | Numeric
Valid value | >=0
Default value | None
Requires attributes ... | `REOPEN`
Conflicts with attributes ... | None
Corresponds to .... | `MAX_FAILURE`, `FAILURE_COUNT`, and `REOPEN_SECS` columns of the `V$ARCHIVE_DEST` view

Usage Notes

- The `MAX_FAILURE` attribute is optional. By default, there are an unlimited number of archival attempts to the failed destination.

- This attribute is useful for providing failure resolution for destinations to which you want to retry transmitting redo data after a failure, but not retry indefinitely.

- When you specify the `MAX_FAILURE` attribute, you must also set the `REOPEN` attribute. Once the specified number of consecutive attempts is exceeded, the destination is treated as if the `REOPEN` attribute was not specified.

- You can view the failure count in the `FAILURE_COUNT` column of the `V$ARCHIVE_DEST` fixed view. The related column `REOPEN_SECS` identifies the `REOPEN` attribute value.

  Note: Once the failure count for the destination reaches the specified `MAX_FAILURE` attribute value, the only way to reuse the destination is to modify the `MAX_FAILURE` attribute value or any attribute. This has the effect of resetting the failure count to zero (0).

- The failure count is reset to zero (0) whenever the destination is modified by an `ALTER SYSTEM SET` statement. This avoids the problem of setting the `MAX_FAILURE` attribute to a value less than the current failure count value.

- Once the failure count is greater than or equal to the value set for the `MAX_FAILURE` attribute, the `REOPEN` attribute value is implicitly set to zero, which causes redo transport services to transport redo data to an alternate destination (defined with the `ALTERNATE` attribute) on the next archival operation.

- Redo transport services attempt to archive to the failed destination indefinitely if you do not specify the `MAX_FAILURE` attribute (or if you specify `MAX_FAILURE=0`), and you specify a nonzero value for the `REOPEN` attribute. If the destination has the `MANDATORY` attribute, the online redo log file is not reusable until it has been archived to this destination.

Examples

The following example allows redo transport services up to three consecutive archival attempts, tried every 5 seconds, to the `arc_dest` destination. If the archival operation fails after the third attempt, the destination is treated as if the `REOPEN` attribute was not specified.

    LOG_ARCHIVE_DEST_1='LOCATION=/arc_dest REOPEN=5 MAX_FAILURE=3'
    LOG_ARCHIVE_DEST_STATE_1=ENABLE

## NET_TIME OUT

Specifies the number of seconds the log writer process on the primary system waits for status from the network server (LNSn) process before terminating the network connection.

Category | NET_TIMEOUT=seconds
--- | ---
Data type | Numeric
Valid values | 1Foot 1 to 1200
Default value | 180 seconds
Requires attributes ... | `LGWR` with `SYNC`
Conflicts with attributes ... | `ARCH`, `LOCATION`, `LGWR` with `ASYNC` Foot 2
Corresponds to ... | `NET_TIMIEOUT` column of the `V$ARCHIVE_DEST` view of the primary database

Footnote 1 Although a minimum value of 1 second is allowed, Oracle recommends 8 to 10 seconds as a minimum to avoid false errors and disconnection from the standby database.

Footnote 2 If you specify the `LGWR` and `ASYNC` attributes, redo transport services ignore them; no error is returned.

Usage Notes

- The `NET_TIMEOUT` attribute is optional. However, if you do not specify the `NET_TIMEOUT` attribute it will be set to 180 seconds, but the primary database can potentially stall. To avoid this situation, specify a small, nonzero value for the `NET_TIMEOUT` attribute so the primary database can continue operation after the user-specified timeout interval expires when waiting for status from the network server.

- The `NET_TIMEOUT` attribute is used only when the log writer process transmits redo data using a network server (LNSn) process.

- The log writer process waits for the specified amount of time to receive status about the network I/O. If there is a possible network disconnection, even one that was terminated due to a network timeout, the l og writer process automatically tries to reconnect to the standby database to resolve network brownouts and false network terminations. Typically, except when the network is physically broken, the log writer process can successfully reconnect to the network. The reconnection attempts continue for a period of time that depends on the following factors:

  - The value of the `NET_TIMEOUT` attribute on the primary database.

  - The p rotection mode of the primary database, which determines the maximum amount of time that the reconnection will take. Use the following time estimates as a guideline for how long the log writer process will try to reconnect to the standby database:

    - In maximum protection mode, the log writer process tries to reconnect for approximately 5 minutes.

    - In maximum availability mode, the log writer process tries to reconnect within the `NET_TIMEOUT` value.

  For example, a primary database operating in the maximum availability protection mode with a `NET_TIMEOUT` attribute value set to 60 seconds could actually take a minimum of 1 minute to connect or up to 3 minutes to terminate the connection to the standby database.

  Caution: Be careful to specify a reasonable value for the `NET_TIMEOUT` attribute when running in maximum protection mode. A false network failure detection might cause the primary instance to shut down.

- Without careful coordination of the timeout parameter values on the primary and standby systems, it is possible that the primary system might detect a network problem and disconnect, while the standby database might not recognize the network disconnection if its default network timeout values are too high. If the network timers are not set up properly, subsequent attempts by the log writer process on the primary database to attach to the standby database will fail because the standby database has not yet timed out and the broken network connection still appears to be valid. See Oracle Database Net Services Administrator's Guide.

Examples

The following example shows how to specify a 40-second network timeout value on the primary database with the `NET_TIMEOUT` attribute.

    LOG_ARCHIVE_DEST_2='SERVICE=stby1 LGWR NET_TIMEOUT=40 SYNC'
    LOG_ARCHIVE_DEST_STATE_2=ENABLE

## NOREGISTER

Indicates that the location of the archived redo log file should not be recorded at the corresponding destination.

Category | NOREGISTER
--- | ---
Data type | Keyword
Valid values | Not applicable
Default value | Not applicable
Requires attributes ... | `SERVICE`
Conflicts with attributes ... | `LOCATIONt`
Corresponds to ... | `DESTINATION` and `TARGET` columsn of the `V$ARCHIVE_DEST` view

Usage Notes

- The `NOREGISTER` attribute is optional if the standby database destination is a part of a Data Guard configuration.

- The `NOREGISTER` attribute is required if the destination is not part of a Data Guard configuration.

- This attribute pertains to remote destinations only. The location of each archived redo log file is always recorded in the primary database control file.

Examples

The following example shows the `NOREGISTER` attribute:

    LOG_ARCHIVE_DEST_5='NOREGISTER'

## REOP EN

Specifies the minimum number of seconds before redo transport services should try to reopen a failed destination.

Category | REOPEN [=seconds]
--- | ---
Data Type | Numeric
Valid values | >=0 seconds
Default Value | 300 seconds
Requires attributes ... | None
Conflicts with attributes ... | `Not applicable`
Corresponds to ... | `REOPEN_SECS` and `MAX_FAILURE` columns of the `V$ARCHIVE_DEST` view

Usage Notes]

- The `REOPEN` attribute is optional.

- Redo transport services attempt to reopen failed destinations at log switch time.

- Redo transport services check if the time of the last error plus the `REOPEN` interval is less than the current time. If it is, redo transport services attempt to reopen the destination.

- `REOPEN` applies to all errors, not just connection failures. These errors include, but are not limited to, network failures, disk errors, and quota exceptions.

- If you specify `REOPEN` for an `OPTIONAL` destination, it is possible for the Oracle database to overwrite online redo log files if there is an error. If you specify `REOPEN` for a `MANDATORY` destination, redo transport services will stall the primary database when it is not possible to successfully transmit redo data. When this situation occurs, consider the following options:

  - Change the destination by deferring the destination, specifying the destination as optional, or changing the `SERVICE` attribute value.

  - Specify an alternate destination.

  - Disable the destination.

  See Also: Section 5.5, "What to Do If Errors Occur" for more information about using the `REOPEN`, `MAX_FAILURES`, and `ALTERNATE` attributes to specify what actions are to be taken when archival processing to a destination fails

Examples

The following example shows the `REOPEN` attribute.

    LOG_ARCHIVE_DEST_3='SERVICE=stby1 MANDATORY REOPEN=60'
    LOG_ARCHIVE_DEST_STATE_3=ENABLE

## S YNC and ASYNC

Specifies that network I/O is to be done synchronously (`SYNC`) or asynchronously (`ASYNC`) when archival is performed using the log writer process (`LGWR`).

Note: When the primary database is in maximum protection mode or maximum availability mode, destinations archiving to standby redo log files and using the log writer process are automatically placed in `SYNC` mode.

Category | SYNC | ASYNC
--- | --- | ---
Data type | Keyword | Numeric
Valid values | Not applicable | Not applicable
Default value | Not applicable | None
Requires attributes ... | None | `LGWR`
Conflicts with attributes ... | `ASYNC` | `SYNC`, `LOCATION`, `ARCH`
Corresponds to ... | `TRANSMIT_MODE` column of the `V$ARCHIVE_DEST` view | `TRANSMIT_MODE` and `ASYNC_BLOCKS` columns of the `V$ARCHIVE_DEST` view

Usage Notes

- The `SYNC` and `ASYNC` attributes are optional:

  - When you specify the `LGWR` attribute but you do not specify either the `SYNC` or `ASYNC` attribute, the default is `SYNC`.

  - When you specify the `ARCH` attribute, only the `SYNC` attribute is valid. An error message is returned if you specify the `ARCH` and `ASYNC` attributes together.

- The `SYNC` attribute specifies that network I/O is to be performed synchronously for the destination, which means that once the I/O is initiated, the log writer process waits for the I/O to complete before continuing. The `SYNC` attribute is one requirement for setting up a no-data-loss environment, because it ensures the redo records are successfully transmitted to the standby destination before continuing.

- The `ASYNC` attribute specifies that network I/O is to be performed asynchronously for the destination.

Examples

The following example shows the `SYNC` attribute with the `LOG_ARCHIVE_DEST_``n` parameter.

    LOG_ARCHIVE_DEST_3='SERVICE=stby1 LGWR SYNC'
    LOG_ARCHIVE_DEST_STATE_3=ENABLE

## TEMPLATE

Defines a directory specification and format template for names of archived redo log files at the destination. The template is used to generate a filename that is different from the default filename format defined by the `STANDBY_ARCHIVE_DEST` and `LOG_ARCHIVE_FORMAT` initialization parameters at the standby destination.

Category | TEMPLATE=filename_template_%t_%s_%r
--- | ---
Data Type | String value
Valid values | Not applicable
Default Value | None
Requires attributes ... | `SERVICE`
Conflicts with attributes ... | `LOCATION`
Corresponds to ... | `REMOTE_TEMPLATE and REGISTER columns of the` `V$ARCHIVE_DEST` view

Usage Notes

- The `TEMPLATE` attribute is optional. If `TEMPLATE` is not specified, archived redo logs are named using the value of the `STANDBY_ARCHIVE_DEST` and `LOG_ARCHIVE_FORMAT` initialization parameters.

- The `TEMPLATE` attribute overrides the `STANDBY_ARCHIVE_DEST` and `LOG_ARCHIVE_FORMAT` initialization parameter settings at the remote archival destination.

- The `TEMPLATE` attribute is valid only with remote destinations (that is, destinations specified with the `SERVICE` attribute).

- If specified for a destination that also specifies the `LGWR` attribute, rearchiving by the ARCn process does not use the `TEMPLATE` filename specification.

- The value you specify for filename_template must contain the %s, %t, and %r directives described in Table 14-1.

  Table 14-1 Directives for the TEMPLATE Attribute

  Directive | Description
  --- | ---
  `%t` | Substitute the instance thread number.
  `%T` | Substitute the instance thread number, zero filled.
  `%s` | Substitute the log file sequence number.
  `%S` | Substitute the log file sequence number, zero filled.
  %r | Substitute the resetlogs ID.
  %R | Substitute the resetlogs ID, zero filled.

- The filename_template value is transmitted to the standby destination, where it is translated and validated before creating the filename.

Examples

In the following example, `prmy1` transmits redo data to the remote destination, `stby1`. The `TEMPLATE` attribute indicates that `stby1` is located in the directory `/usr/oracle/prmy1` with the `p1_``thread#_sequence#_resetlogs``.dbf` filename format.

    LOG_ARCHIVE_DEST_1='SERVICE=boston MANDATORY REOPEN=5
        TEMPLATE=/usr/oracle/prmy1/p1_%t_%s_%r.dbf'
    LOG_ARCHIVE_DEST_STATE_1=ENABLE

## V ALID_FOR

Specifies when redo transport services transmit redo data to a destination, based on the following factors:

- Whether the database is currently running in the primary or the standby role

- Whether online redo log files, standby redo log files, or both are currently being archived on the database at this destination

Category | VALID_FOR=(redo_log_type, database_role)
--- | ---
Data Type | String value
Valid values | Not applicable
Default Value | `VALID_FOR=(ALL_LOGFILES, ALL_ROLES)` Foot 1
Requires attributes ... | None
Conflicts with attributes ... | None
Corresponds to ... | `VALID_NOW`, `VALID_TYPE`, and `VALID_ROLE` columns in the `V$ARCHIVE_DEST` view

Footnote 1 Do not use the default value, `VALID_FOR=(ALL LOGFILES, ALL_ROLES)`, for logical standby databases. See Section 5.4.1 and the scenario in Section 12.1.2 for more information.

Usage Notes

- The `VALID_FOR` attribute is optional. However, Oracle recommends that you define a `VALID_FOR` attribute for each destination so that your Data Guard configuration operates properly after a role transition.

  Note: Although the `(ALL_LOGFILES,ALL_ROLES)` keyword pair is the default, it is not appropriate for every destination. For example, if the destination is a logical standby database, which is an open database that is creating its own redo data, the redo data being transmitted by redo transport services could potentially overwrite the logical standby database's local online redo log files.

- To configure these factors for each `LOG_ARCHIVE_DEST_``n` destination, you specify this attribute with a pair of keywords: `VALID_FOR=(`redo_log_type`,`database_role`)`:

  - The redo_log_type keyword identifies the destination as valid for archiving one of the following:

    - `ONLINE_LOGFILE`—This destination is valid only when archiving online redo log files.

    - `STANDBY_LOGFILE`—This destination is valid only when archiving standby redo log files.

    - `ALL_LOGFILES`— This destination is valid when archiving either online redo log files or standby redo log files.

  - The database_role keyword identifies the role in which this destination is valid for archiving:

    - `PRIMARY_ROLE`—This destination is valid only when the database is running in the primary role.

    - `STANDBY_ROLE`—This destination is valid only when the database is running in the standby role.

    - `ALL_ROLES`—This destination is valid when the database is running in either the primary or the standby role.

- The following table shows the `VALID_FOR` attribute values and the roles in which each might be used.

  Table 14-2 VALID_FOR Attribute Values

  VALID_FOR Definition | Primary Role | Physical Standby Role | Logical Standby Role
  --- | --- | --- | ---
  `ONLINE_LOGFILE, PRIMARY_ROLE` | Active | Inactive | Invalid
  `ONLINE_LOGFILE, STANDBY_ROLE` | Inactive | Invalid | Active
  `ONLINE_LOGFILE, ALL_ROLES` | Active | Invalid | Active
  `STANDBY_LOGFILE, PRIMARY_ROLE` | Error | Error | Error
  `STANDBY_LOGFILE, STANDBY_ROLE` | Invalid | Active | Active
  `STANDBY_LOGFILE ALL_ROLES` | Invalid | Active | Active
  `ALL_LOGFILES, PRIMARY_ROLE` | Active | Inactive | Invalid
  `ALL_LOGFILES, STANDBY_ROLE` | Invalid | Active | Active
  `ALL_LOGFILES, ALL_ROLES` | Active | Active | Active

  Note: The `VALID_FOR=(STANDBY_LOGFILE, PRIMARY_ROLE)` keyword pair is not possible; although it is valid to configure standby redo log files on a primary database, a database that is running in the primary role cannot use standby redo log files.

- If you do not specify the `VALID_FOR` attribute for a destination, by default, archiving online redo log files and standby redo log files is enabled at the destination, regardless of whether the database is running in the primary or the standby role. This default behavior is equivalent to setting the `(ALL_LOGFILES,ALL_ROLES)` keyword pair on the `VALID_FOR` attribute. For example:

      LOG_ARCHIVE_DEST_1='LOCATION=/disk1/oracle/oradata/payroll/arch/
        VALID_FOR=(ALL_LOGFILES,ALL_ROLES)

- The `VALID_FOR` attribute enables you to use the same initialization parameter file for both the primary and standby roles.

Example

The following example shows the default `VALID_FOR` keyword pair:

    LOG_ARCHIVE_DEST_1='LOCATION=/disk1/oracle/oradata VALID_FOR=(ALL LOGFILES, ALL_ROLES)'

When this database is running in either the primary or standby role, destination 1 archives all log files to the `/disk1/oracle/oradata` local directory location.

See the scenarios in Section 12.1 for detailed examples of various Data Guard configurations using the `VALID_FOR` attribute.

## V E RIFY

Indicates whether or not an archiver (ARCn) process should scan and verify the correctness of the contents of a completed archived redo log file, either local or remote, after successfully completing the archival operation.

Category | VERIFY
--- | ---
Data Type | Keyword
Valid values | Not applicable
Default Value | Not applicable
Requires attributes ... | None
Conflicts with attributes ... | `LGWR`
Corresponds to ... | `VERIFY` `and ARCHIVER columns in the V$ARCHIVE_DEST` view

Usage Notes

- If the `VERIFY` attribute is not specified, archived redo log files will not be verified.

- The verification is significantly more thorough than the normal checksum verification that is always performed; the redo verification may take a substantial amount of time to complete.

- The use of the `VERIFY` attribute may have an affect on primary database performance.

Example

The following example shows the `VERIFY` attribute:

    LOG_ARCHIVE_DEST_1='LOCATION=/disk1/oracle/oradata VERIFY'
    LOG_ARCHIVE_DEST_2='LOCATION=/arch1/SRLs/ VALID_FOR=(STANDBY_LOGFILE, STANDBY_ROLE) VERIFY'
    LOG_ARCHIVE_DEST_3='SERVICE=denver VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE) VERIFY'